Natürlich ging es auf den JavaScript Days 2019 um Angular und React. Die beiden Frameworks stehen im Zentrum der Aufmerksamkeit, wenn es um das Ökosystem geht! Aber auch, wenn man einen Schritt zurück geht und nicht über Frameworks spricht, sondern über JavaScript selbst, gibt es einige spannende Entwicklungen zu berichten. Genau das beleuchten wir im Interview mit Peter Kröner von den JavaScript Days. Wie hat sich JavaScript in den letzten Jahren entwickelt, wo bewegt sich die Sprache hin? Was hat sich an der Programmiersprache verbessert, wo könnte noch nachgebessert werden? Diese Fragen beleuchtet der Speaker im Interview.
JavaScript Days: Fangen wir doch mal mit JavaScript als Sprache und der Syntax an sich an. Was hat sich so in der letzten Zeit bei den syntaktischen Funktionen in JavaScript getan?
Peter Kröner: Syntaktisches gab es jetzt nicht so viel Neues, es ist halt ein bisschen Nachrüsten von dem ganzen Zeug, also Syntax kommt nach und nach immer mal wieder in die Sprache, das ist im Prinzip die große Baustelle. Es ist schwer zu sagen, wann genau da was neu gelandet ist. Es ist natürlich so, dass sich so Dinge wie Object Spread langsam stabilisieren. Es gibt ein paar neue Funktionen, die eingeführt werden, wie Object Entries als Ergänzung zu den ganzen Entry-Methoden von Maps und Sets und Ähnlichem. Es ist halt das Übliche, es wird eben Kleinkram nachgerüstet.
JavaScript Days: Ein großes Thema über die Jahre bei JavaScript war ja immer auch die Asynchrone Ausführung von Code. Was hat sich in diesem Bereich getan?
Peter Kröner: Das ist meiner Meinung nach das einzige, von dem man sagen kann, da hat sich was an der Sprache per se geändert. Man kann aus der Sprache ja nichts entfernen, weil sonst bestehende Websites kaputtgehen würden. Man kann immer nur Dinge hinzufügen und meist werden eben kleine Syntaxänderungen hinzugefügt, die alle sehr hilfreich sind, die einen aber nicht zum großen Umdenken bringen. Man baut dann immer noch seine Websites, genau wie vor hundert Jahren, mit irgendwie anders benannten Features und es heißt jetzt eben let statt var, aber im Prinzip ist es das Gleiche. Man macht jedoch nicht wirklich was Neues anders und diese Asynchronität ist das einzige Gegenteil, da ist es mit Hilfe von async und await wirklich möglich, asynchronen Code mit imperativen Sprachmitteln zu formulieren. Das ging vorher nicht, denn da waren asynchroner Code mit Callbacks und imperativer Code mit Schleifen und if und else zwei getrennte Welten, die jetzt wieder zusammengeführt werden. Und das kann bei denen, die das komplett durchdrungen haben, dazu führen, dass Dinge einfacher werden, besser zu verstehen sind und man Code anders strukturiert. Man kann Dinge ganz anders ausdrücken, und das ist tatsächlich auch der große Brustlöser. Jetzt würde ich von JavaScript in Zukunft auch erwarten, dass in der Richtung ein bisschen mehr kommt.
JavaScript Days: Andererseits gibt es ja auch wegen der Veränderungen über die Jahre immer wieder Stiländerungen im Code. Gibt es bei JavaScript etwas, von dem man sagen kann, das hat man früher so gemacht, das macht man heute aber lieber nicht mehr so?
Peter Kröner: Sicherlich gehört da zum Beispiel das Callback Chaos dazu, also irgendwelche verschachtelten Funktionen, um verschiedene Sequenzen abzubilden, das wird durch async und await ersetzt. Und sonst ist es auf der syntaktischen Ebene so, dass es Sprachfeatures gibt wie zum Beispiel das angesprochene var zum Deklarieren von Variablen, das macht man nicht mehr, weil let und const grob das Gleiche machen. Und da haben wir das Problem wieder: Es ist halt immer grob das Gleiche, aber weniger fehleranfällig, denn man hat ein paar Schutzmechanismen eingebaut, dass man weniger offensichtliche, doofe Programmierfehler begeht. Insgesamt ist man damit ein bisschen besser dran.
JavaScript Days: Die Module in JavaScript, im Speziellen in ECMAScript, sind jetzt nicht mehr ganz so neu. Wie hat sich denn die Welt mit dem modularisierten Code in JavaScript entwickelt in den letzten Jahren?
Peter Kröner: Das ist ein dickes Brett, das man da gerade bohrt. Das ist jetzt im Browser weitestgehend angekommen, dass man auch die import und export Keywords benutzt. Bei Node.js geht der Kampf noch weiter, da gibt es auf jeden Fall eine ganze Menge technischer Probleme, die jetzt für dieses kurze Format viel zu langwierig zu erklären wären. Es ist eben so: Wenn wir JavaScript und ECMAScript als die Sprache betrachten, dann sind die sicherlich angekommen und stabilisiert und alles ist gut. Mittlerweile gibt es sogar eine offizielle Syntax, um Module zur Laufzeit dynamisch nachzuladen. Das ist alles ganz fein, das muss sich nur eben noch in Node.js festsetzen, das ist Punkt 1. Punkt 2 ist, dass es in allen Libraries landen muss, damit man auch wirklich die Vorteile einheimsen kann. Denn man will mit dem alternativen Modulsyntax unter anderem erreichen, dass man aus Modulen einzelne Funktionen importieren kann, und nicht, dass das ganze Modul am Ende im Output landet und die Downloadgröße ewig groß macht. Dazu müssen aber die ganzen alten Bestandscodekonstrukte, die es bereits gibt, irgendwie aufgebohrt werden, was jetzt auch so langsam nach und nach passiert. Die ganzen neuen, modernen Tools, die Tree Shaking können, müssen benutzt werden und das alles muss natürlich auch zweckmäßig eingesetzt werden. Da ist auf der technischen Seite schon ziemlich viel erreicht, das Problem sitzt halt meist vor dem Bildschirm: Man könnte so viel Schönes machen, es ist halt immer ein bisschen schwierig, auch weil es immer mehr wird.
JavaScript Days: Wie sieht es aus mit dem Verhältnis von ECMAScript und TypeScript? TypeScript gilt ja immer noch als der große Trend und das schon seit Jahren. Wie verbreitet und beliebt ist denn diese Variante jetzt wirklich?
Peter Kröner: Das kann ich jetzt gar nicht so genau sagen, aber npm, also das zentrale Package Repository, hat dazu Statistiken, und die zeigen scheinbar tatsächlich, dass TypeScript auf dem Weg ist, die gesamte JavaScript-Welt zu verspeisen. Da glaube ich aber nicht so ganz dran. Bei TypeScript ist es so, dass man es unterschiedlich verwenden kann, und meist verwendet wird es als eine statisch typisierte Programmiersprache im Sinne der ganzen Mainstream-OOP-Sprachen wie Java und C#. Das kann man so machen, wenn man auf sowas steht, man könnte aber tatsächlich TypeScript wie eine Art besseres JavaScript verwenden, sprich JavaScript-Programmierparadigmen und die Dinge, die man in den anderen Sprachen nicht tun würde, in JavaScript schreiben, mit Hilfe von TypeScript type-safe gestalten und auch begleiten, dass Dinge wie Typinferenz usw. ein bisschen helfen. Wenn man halt diesen Aspekt von TypeScript ein bisschen mehr pushen würde, etwas mehr in die Welt hereintragen und den Leuten genauer beibringen würde, anstatt zu sagen: „Du musst jetzt schreiben ‚class a extends b implements c‘“. Dann würde sich das sicherlich noch mehr verbreiten. Das wächst im Moment so stark, weil es halt eben bei der Enterprise-Fraktion mit „class a extends b implements c“ gut ankommt, weil die das eben gut machen können. Aber die andere Fraktion, die Webentwickler, fragt sich: „Warum muss ich denn da dranschreiben, dass es eine Zahl ist, das sehe ich doch so, ich brauch diese ganzen Typannotationen nicht“ – und die haben damit Recht. Man muss dieses Werkzeug eben zweckmäßig einsetzen. Schauen wir mal, ob wir das hinkriegen, denn solange wir nur auf dieser Enterprise-Schiene fahren, nehmen wir nicht alle mit und das finde ich schade.
JavaScript Days: Du hast es ja gerade schon angesprochen, die Paradigmen der Entwickler und die verschiedenen Vorstellungen davon, wie Sachen implementiert werden sollen. Was sind denn noch andere typische Hürden, die man im Moment für den Einstieg in die Arbeit mit JavaScript sieht?
Peter Kröner: Da würde ich ganz klar sagen, dass es alles unglaublich viel ist. Es ist jetzt nicht mehr ganz so schlimm, dass sich ständig alles ändert, aber die schiere Masse und die schiere Unstrukturiertheit machen es glaub ich vielen schwer. Was ich so erfahre, wenn ich durch die Firmen gehe und irgendwelchen Java-Entwicklern JavaScript beibringe, ist, dass es da eben nicht den einen Hersteller gibt, der sagt, wie es läuft und der die Implementierung und eine Dokumentation liefert, sondern alles verstreut sich überall. Wenn du mich fragst, wird das auch nicht besser werden, denn JavaScript ist wirklich ein Ökosystem im Sinne des Wortes, alles ein bisschen bunt und durcheinander, wie ein Tümpel, in dem diverse Sachen rumschwimmen, im Gegensatz zu einem Produkt wie C#, poliert und dokumentiert. Das bekommen wir nicht in JavaScript und werden wir auch nie kriegen, und das ist auch gut so, denn die Alternativen haben wir ja schon in den anderen Sprachen.
JavaScript Days: Andererseits ist dieses Ökosystem für sich genommen ein ganz spannendes Thema. Was denkst du denn, was dieses Jahr der große Trend im JavaScript-Ökosystem ist?
Peter Kröner: Ich habe keine Ahnung, ich weiß es wirklich nicht. Zu mir kommen immer häufiger Leute, die irgendwie die Web Components wieder ausgegraben haben wollen, von denen man jetzt schon längere Zeit nichts mehr gehört hat, vielleicht wird es ja das. Ansonsten kann man natürlich sagen, der aktuelle Wachstumsmarkt ist sowas Vue. Ich bin jetzt in den Frameworks nicht ganz so drin, aber das ist das, von dem alle reden. Damit müsste man sich jetzt mal befassen, das sind so die zwei Dinge, von denen ich sagen würde, da scheint es zumindest ein bisschen Interesse zu geben: Vue.js und Web Components.
JavaScript Days: Gibt es vielleicht in der Programmiersprache selbst irgendwas, von dem du sagen würdest, das sollte man nochmal stärker fördern?
Peter Kröner: Oh ja! Es müsste mehr neue Dinge geben, die in die Richtung von async/await gehen und weniger Syntaxkrempel. Syntaxkrempel ist ja irgendwie ganz nett, aber wenn man erstmal über eine gewisse Schwelle drüber gekommen ist und viele Möglichkeiten hat, sich auszudrücken, wird es halt komplizierter. Man bekommt immer mehr Varianten, muss sich ständig entscheiden und das führt dann eben zu Entscheidungsmüdigkeit und macht dann auch kein Spaß mehr. Mittlerweile würde ich sagen, wir sind syntaktisch auf einem Niveau angekommen, wo man wirklich im Prinzip alles, was man im Alltag ausdrücken möchte, einigermaßen elegant auf die Reihe bekommt. Jetzt brauchen wir wirklich etwas, was das Denken und Programmieren verändert. async/await ist zum Beispiel so eine Sache, mit der man durch ein paar neue Keywords und ein bisschen Hexerei und Trickserei plötzlich imperatives Programmieren für asynchronen Code möglich macht. Also wirklich was Neues, Fundamentales –und das will ich haben. Also wenn du mich jetzt fragst, was ich dringend brauche, dann würde ich mir wünschen, dass ich bei den neuen Datenstrukturen wie Maps und Sets selbst definieren kann, was ich unter Gleichheit verstehe bei irgendwelchen Keys und Values, die Objekte sind. Normalerweise bin ich einfach auf den Gleichheitsalgorithmus von JavaScript angewiesen, der mir sagt, Objekte werden per Identität verglichen. Aber wenn ich z. B. Objekte habe, die ich als Wert vergleichen möchte, gibt es keine Möglichkeit, diesen nativen Datenstrukturen das beizubringen. Ich müsste meinen eigenen schreiben, und das ist fehleranfällig und anstrengend – das will man alles nicht. Solche Low-Level-Eingriffsmöglichkeiten, die würde ich haben wollen. Die sollten dringend optional und nicht zu mächtig sein, aber die würden vieles Neues möglich machen. Metasachen, die wirklich das Denken verändern, und das könnte der Sprache noch guttun.
